Dynomotion

Group: DynoMotion Message: 1818 From: bradodarb Date: 9/24/2011
Subject: Coord Buffer
Hello Tom,


I'm sure there is a good reason for not doing it, but I'm curious to know what your thoughts are on automatically increasing the buffer look ahead on an underflow condition.

Or possibly have a flag you can set to try and optimize it dynamically.

if the flag is set to true:
When a buffer overflow occurs can we auto-increment it by a set value?

Or maybe see how long the defficiency was and try to increase it by that plus a safety factor?



I think with some applications you want to know about the underflow and the error is good so you can adjust to optimize your process; but for the interpreter I just cant seem to find folly in loosening things up a bit.


What are your thoughts?

-Brad Murry
Group: DynoMotion Message: 1819 From: Tom Kerekes Date: 9/24/2011
Subject: Re: Coord Buffer
Hi Brad,
 
I guess my feeling is that would make the issue more obscure and confusing.  I think a value of 3 seconds should work on most any system but then on a really clean/fast Windows box a User might risk reducing it to maybe 1 second to get better on-the-fly feedrate response.  Have you had a different experience?  Of course you can do whatever you wish from your application.
 
I've often wondered if it might make sense to do something in KFLOP where instead of simply starving for data, detect the buffer is starting to run low, and start reducing the feedrate and/or do a feedhold until the buffer increases again.
 
But the price for adding extra complexity such as this it that it can mask other problems and make diagnosing problems more difficult.  So far I think most of the Buffer Underflow errors have been due to a configuration problem or a software bug, and once corrected no longer becomes an issue.
 
Regards
TK
 
 
 
 
 

Group: DynoMotion Message: 1820 From: bradodarb Date: 9/24/2011
Subject: Re: Coord Buffer
Hello Tom,

I agree that it would add complexity. I think if it were implemented it would be best to be able to toggle over both behaviors. The current system would be preserved, but you could set a boolean flag to auto adjust for certain applications.

I am using a quadcore xeon 3.6ghz with 12 gigs of ram and win7x64.
When I have the tp-lookahead set to 1 second with high feedrates I ocasionally get the dreaded buffer underflow.

Thanks
-Brad Murry

--- In DynoMotion@yahoogroups.com, Tom Kerekes <tk@...> wrote:
>
> Hi Brad,
>  
> I guess my feeling is that would make the issue more obscure and confusing.  I think a value of 3 seconds should work on most any system but then on a really clean/fast Windows box a User might risk reducing it to maybe 1 second to get better on-the-fly feedrate response.  Have you had a different experience?  Of course you can do whatever you wish from your application.
>  
> I've often wondered if it might make sense to do something in KFLOP where instead of simply starving for data, detect the buffer is starting to run low, and start reducing the feedrate and/or do a feedhold until the buffer increases again.
>  
> But the price for adding extra complexity such as this it that it can mask other problems and make diagnosing problems more difficult.  So far I think most of the Buffer Underflow errors have been due to a configuration problem or a software bug, and once corrected no longer becomes an issue.
>  
> Regards
> TK
>  
>  
>  
>  
>  
>
> From: bradodarb <bradodarb@...>
> To: DynoMotion@yahoogroups.com
> Sent: Saturday, September 24, 2011 7:58 AM
> Subject: [DynoMotion] Coord Buffer
>
>
>  
> Hello Tom,
>
> I'm sure there is a good reason for not doing it, but I'm curious to know what your thoughts are on automatically increasing the buffer look ahead on an underflow condition.
>
> Or possibly have a flag you can set to try and optimize it dynamically.
>
> if the flag is set to true:
> When a buffer overflow occurs can we auto-increment it by a set value?
>
> Or maybe see how long the defficiency was and try to increase it by that plus a safety factor?
>
> I think with some applications you want to know about the underflow and the error is good so you can adjust to optimize your process; but for the interpreter I just cant seem to find folly in loosening things up a bit.
>
> What are your thoughts?
>
> -Brad Murry
>